1. The Field of the Invention
The present invention relates to managing processes on a computer system. More specifically, the present invention relates to mechanisms for detecting termination and providing information related to termination of a computer system process.
2. Background and Related Art
Computers have revolutionized the way we work and play. There are an enormous variety of functions and applications that may be implemented by a general purpose computing system in response to the execution of a software application. The utility and functionality of the computing system does, however, rely on the proper coding of the source code that was compiled or interpreted into the binary instructions that are actually executed by the processor. If there is a coding error, this will often result in a deviation from expected functionality.
Extraordinary efforts are currently in place to reduce the number of unexpected performance deviations in many software programs before and after the software application are shipped to market. However, the creativity of software programmers and designers has led to increasingly complex and powerful software applications. As the complexity of the software application increases, so often does the number of lines of source code needed to generate the software application. In a software application with increased lines of source code, there is a corresponding increase in the potential for introducing instructions that will cause a software application to deviate from expected performance. Further, there is always some potential for the instructions of a software application to cause the software application to terminate without providing any information related to the cause of the termination (hereinafter referred to as “undetected termination”).
Undetected termination of a software application can occur when the software application includes a default behavior for handling otherwise unhandled exceptions generated by the software application. Deviation from expected performance at run-time (e.g., due to execution of an invalid instruction) can cause an error, often referred to as an “exception”. When a code layer that caused an exception does not include instructions for handling the exception, the exception can be propagated to other code layers until instructions for handling the exception are located. For example, a software application may execute an invalid instruction that attempts to write data to memory address zero. Since computer systems typically do not allow access to memory address zero, execution of the invalid instruction results in an access violation exception. If the software application does not include appropriate instructions for handling the access violation exception, the access violation exception can be referred to as an “unhandled” exception (i.e., the software application does not handle the access violation exception) and can be propagated to an operating system code layer.
When the operating system code layer receives an unhandled exception, the operating system code layer can handle the unhandled exception by launching a debugger or crash monitor that provides information related to the unhandled exception. For example, a debugger or crash monitor can provide register values, a memory dump, and/or an event log that represent the state of the computer system at the time the unhandled exception occurred. This is beneficial as a developer or user of the software application is provided information that may be useful in determining the cause of the unhandled expectation. Unfortunately, it may be difficult for a software application that caused an unhandled expectation to recover and resume executing instructions. For example, the software application may freeze and there may be not way to return execution back to the software application.
Accordingly, software developers can include instructions for catching and handling exceptions a software application might generate or otherwise encounter. Many software applications are designed to catch at least common exceptions and appropriately handle the common exceptions in a manner that allows the software application to continue functioning. Unfortunately, some software developers may lack the desire and/or knowledge to implement instructions that check for all possible handles exceptions a software application might generate or otherwise encounter. On the other hand, more conscientious software developers may include substantial error checking and exception handling code, in an attempt to handle all possible exceptions an application program might generate or otherwise encounter. However, there is always some potential for even a conscientious software developer to develop a software application that lacks appropriate instructions for handling at least some exceptions.
Thus, during the execution of a software application there is always a possibility that an exception will go unhandled by exception handling mechanisms expressly included in the software application. As a result, some compilers insert code into software applications that handle exceptions in a default manner when the exceptions are not otherwise handled by expressly included exception handling mechanisms. For example, it may be that a software application developed in C++ source code does not include instructions for catching and handling C++ exceptions. Thus, when the software application generates a C++ exception, the C++ exception is handled in the default manner. The default manner can include returning execution to a “main” function that attempts to handle the exception. If the main function cannot handle the exception, the main function calls an “exit” function causing the software application to terminate. That is, the main function handles the C++ exception by terminating the software application.
Since the main function handles the C++ exception, the C++ exception is not propagated to other code layers. Thus, there is limited, if any, chance for an operating system code layer to detect the C++ exception as an unhandled exception. Accordingly, the operating system code layer does not invoke a debugger or crash monitor and the software application is terminated without providing information related to the cause of the termination.
Undetected termination of a software application can also occur when the software application includes a default behavior for handling appropriate input. For example, a software application may include a conversion function that converts a text representation of message length (e.g., in bytes) to a positive integer. However, the developer of the software application may have failed to consider the possibility of receiving a negative message length and thus may simply pass a negative message length to the conversion function. The conversion function's behavior upon receiving a negative message length may be to call an exit function, which terminates the software application. Thus, if the conversion function was called with a message length of negative one, the conversion function would cause the software application to terminate. However, little, if any, information related to the termination would be provided to a user or developer of the software application.
Although a developer could potentially re-code the conversion function, the developer may lack access to the source code (e.g., in C++, C#, or Visual Basic) for a software application. Instead, the software developer may have access only to machine and/or object instructions (e.g., an executable program or dynamic link library (“DLL”)) generated as a result of compiling the source code. Thus, even if a developer has the desire, ability, and appropriate tools for re-coding a function to provide information related to the termination of a software application, the developer may nonetheless be prevented from implementing the functionality.
When a software application is executed, one or more process may be loaded into system memory. Many processes are loaded into system memory to perform automated tasks that do not require user-input to function. For example, a loaded process can monitor ports of a computer system for incoming electronic messages. Many operating systems (as well as other software systems) include the functionality to display a “task list” of processes that are loaded in memory. For example, in some Microsoft® Windows® environments, a computer system user or administrator can activate a key combination of the “Ctrl”, “Alt”, and “Delete” keys to display a task list. Thus, a user or administrator can view processes (even some background processes) running on a corresponding computer system.
Unfortunately, due to default exception handling and/or the default behavior of a function, undetected termination of memory resident processes can occur. That is, termination of the process can occur without an error message being presented at the computer system (either from the terminating process or the operating system). Thus, a user or administrator may become aware that the terminated process is no longer running only after actions typically performed by the process (e.g., automatically checking for electronic mail messages) do not occur. Accordingly, what would be advantageous are mechanisms for detecting termination and providing information related to termination of a computer system process.